Automatic invoice notification

ABSTRACT

Introduced here is a technology for automatic notification of an invoice based on identification of a customer identifier included in transaction data received from a point-of-sale (POS) device of a particular merchant. Transaction data for a transaction occurring at the merchant POS device between a customer and the first merchant can be transmitted from the POS device to server(s) of a payment processing service. The transaction data can include a customer identifier. The POS device can receive invoice data from the server(s) associated with an unpaid invoice that is associated with the customer identifier and a historical transaction with the first merchant or a second merchant. The POS device can cause presentation, on a display of the POS device, an invoice payment invitation for the customer to make a payment on the unpaid invoice.

RELATED APPLICATIONS

This Application in a divisional of and claims priority to U.S. patentapplication Ser. No. 16/680,177, filed Nov. 11, 2019, which is acontinuation of and claims priority to U.S. patent application Ser. No.14/701,402, filed Apr. 30, 2015, and issued as U.S. Pat. No. 10,475,011,on Nov. 12, 2019, the entire contents of each are incorporated herein byreference.

BACKGROUND

An invoice is a commercial document, issued by a merchant to a customerin a sales transaction, typically indicating a product sold or servicerendered, a quantity, an agreed transaction amount for the product orservice, and payment terms that specify, among other things, whenpayment is due. Invoices are beneficial to a merchant's business as theyprovide financial flexibility for customers (i.e., delayed payments),thereby incentivizing the customers to engage in transactions with themerchant. However, unpaid invoices, which inherently representunrealized income for the merchant, are recorded as financialliabilities (e.g., account payables). Accordingly, the sooner an invoiceis paid, the more financially healthy is the business.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invoice technology will be described and explainedthrough the use of the accompanying drawings in which:

FIG. 1 illustrates schematically a technique for automaticidentification of an invoice;

FIG. 2 illustrates schematically a technique of generating an invoiceand identifying one or more merchants at which to pay the invoice;

FIGS. 3A-3B are example graphical user interfaces generated by amerchant POS system based on automatic invoice identification;

FIGS. 4A-4B are example graphical user interfaces generated by a userdevice based on automatic invoice identification;

FIG. 5 illustrates various components of a payment service system;

FIG. 6 illustrates example database tables that can be utilized with thedisclosed technology;

FIG. 7 is a flowchart illustrating a set of operations for generating aninvoice with recommended merchants for paying the invoice;

FIG. 8 is a flowchart illustrating a set of operations foridentification and notification of invoice(s) based on receivedtransaction data; and

FIG. 9 illustrates an example of a processing computer system with whichvarious embodiments of the invoice technology can be utilized.

DETAILED DESCRIPTION

Introduced here is technology for automatically identifying andnotifying a customer of a pending (unpaid) invoice, based onidentification of a customer identifier in transaction data receivedfrom a point-of-sale (POS) system of a merchant (“the invoicetechnology”). In particular, the notification can be presented on adisplay of the POS system of the merchant (hereinafter, “POS merchant”).Alternatively, the notification can be presented in a receipt for thetransaction conducted at the POS system, where that receipt can betransmitted for display at a user device of the customer. For example,the receipt can be in the form of an email message or a text message.The notification can include a promotional offer (hereinafter,“promotion”) to provide an incentive to the customer to pay the invoice,such as, for example, a discount or a free product or service providedby the POS merchant. Upon notification of the invoice, the customer cansubmit a payment for that invoice (“invoice payment”) to redeem thepromotion. As a result, the financial liability associated with theinvoice can be resolved faster for the merchant of the invoice (“invoicemerchant”).

Note that the POS merchant who operates the POS system discussed abovecan be either the invoice merchant or a different, second merchant. Inthe case where the POS merchant is a merchant other than the invoicemerchant, the POS merchant who operates the POS system can receive acompensation from the invoice merchant for utilizing the invoicetechnology (thereby enabling the invoice merchant to receive the invoicepayment via more than one avenue). In some instances, the POS system canreceive the compensation from a third-party payment service thatexecutes the invoice technology; for example, the third-party paymentservice is employed by the invoice merchant to collect invoice payments.

Note also that the term “customer identifier” used here refers to anyidentifier that can be used to identify the customer, directly orindirectly, including, for example, a card number of the customer'spayment card (e.g., credit card or debit card), an email address of thecustomer, a phone number of the customer, a biometric identifier of thecustomer, a geographical location (e.g., geographic location data suchas an address, geographical coordinates, etc.) associated with thecustomer, etc. As used here, the term “biometric identifier” refers toany biometric information, or data, that can be provided by a biometricobject of, or belonging to, the customer. An example of a biometricidentifier is a fingerprint or retina pattern. Examples of a biometricobject can include a finger, a hand, an iris, or a face, among others.

In some embodiments, the invoice technology also involves automaticidentification and generation of a list of merchants (e.g., includingthe POS merchant) for inclusion in an invoice provided by the invoicemerchant. Note the invoice discussed here may not relate to thetransaction discussed above. The list of merchants includes one or moremerchants at which the customer can pay the invoice. The list ofmerchants can be generated based on, for example, a spending trend ofthe customer, past transactions of the customer, or a geographicallocation of the customer. For example, where the customer has a spendingtrend of shopping at boutique stores, the list of merchants can includeboutique clothing stores and boutique jewelry stores as recommendedplaces where the invoice can be paid. In another example, where thecustomer has conducted transactions regularly with Coffee Shop X andRestaurant Y, the list of merchants can include these merchants. In yetanother example, where the customer's residential address is included inthe invoice, the list of merchants can include merchants that aregeographically located within a specified distance of that address. Thespecified distance can be configured, or specified, by the invoicemerchant, the customer, a system operator associated with the invoicetechnology, or any combination thereof.

As will be discussed further below, the invoice technology involves anetwork-based payment service system (PSS) that processes, on behalf ofvarious merchants, customer transactions occurring at POS systems of themerchants. The PSS can include an invoice generation module and aninvoice management module. The invoice generation module can beconfigured to receive a request to generate an invoice for a customer,identify a list of one or more merchants as recommended options forwhere the invoice can be paid, and generate the invoice including thelist of one or more merchants. In some instances, the invoice caninclude one or more promotions corresponding to the one or moremerchants to provide an incentive to the customer to pay the invoice atone of the recommended merchants. Based on the list of merchantsincluded in the invoice, a customer can decide, for example, to visit anew coffee shop near her house so that she can take advantage of theinvoice payment capability and receive, for example, a free coffee(based on a promotion, e.g., “Pay your invoice at Bee Café and get afree coffee”).

The invoice management module of the PSS can be configured to receivetransaction data for a transaction conducted between a customer and amerchant at a POS system, identify any pending (unpaid) invoice(s) ofthe customer based on an association between any invoice(s) and acustomer identifier included in the received transaction data, andgenerate an invoice payment invitation to notify the customer and/or themerchant about the one or more invoices. The payment invoice invitationcan include a promotion to provide an incentive to the customer to pay aparticular invoice. As discussed above, the payment invoice invitationcan be displayed (or output in some other manner) by the POS system orby a user device belonging to the customer.

In some instances, in response to the payment invoice invitation, thecustomer can submit, at the POS system, an invoice payment for aparticular invoice of the pending invoice(s) identified for thecustomer. The POS system can transmit invoice payment information aboutthat payment to the invoice management module. In some instances, thecustomer can pay the invoice at a later time (e.g., at home) using auser device belonging to the customer, such as a conventional personalcomputer or tablet computer. Whenever an invoice payment is received fora particular invoice, the invoice management module can transmit amessage to a corresponding invoice merchant notifying that merchant ofthe payment.

In some instances, the promotion discussed above (e.g., the promotionassociated with the list of recommended merchants or the promotionincluded in the invoice payment invitation) can be for a product orservice offered by a POS merchant to provide an incentive to thecustomer to pay the invoice of another merchant (i.e., the invoicemerchant). For example, the promotion can be “Pay invoice and receive afree coffee here on your next visit.” In exchange for providing thispromotion, the POS merchant can receive a compensation amount from theinvoice merchant (e.g., 1% of invoice amount) for helping to collect theinvoice payment from the customer. Such compensation amount can betransferred by the PSS from an account associated with the invoicemerchant to an account associated with the POS merchant, upon the POSmerchant (and/or the PSS) receiving the invoice payment from thecustomer.

In other instances when the invoice is from the POS merchant (i.e., thePOS merchant is the invoice merchant), the POS merchant can still offerthe promotion to provide an incentive to its own customers to payinvoices. For example, the POS merchant can provide an incentive to acustomer to pay an invoice before the due date. In another example, thePOS merchant can provide an incentive to the customer to pay a past-dueinvoice.

Among other benefits, the invoice technology enables an invoice merchantto obtain faster (and/or overdue) invoice payments through any POSsystem that is associated with the PSS, including the invoice merchant'sown POS system(s) and/or other merchants' POS system(s). Furthermore,because identification and notification of an invoice is automaticwhenever a customer conducts a transaction with a POS system associatedwith the PSS, which recognizes the customer (and corresponding invoice)based on an identifier, the invoice technology removes the customer'sburden of having to remember which merchant and/or which invoice stillrequires payment. Additionally, the invoice technology enables thecustomer to submit an invoice payment not only at any POS systemassociated with the PSS, but also at a later time (e.g., at home) usinga user device of the customer.

In this specification, note that the term “sale,” as in point-of-sale(POS) or sales system used throughout this specification, can refer toany type of payment-oriented transaction, including a lease or rentalfor example, and is not limited to an actual purchase. Accordingly, theinvoice technology can be implemented to collect details about, forexample, an equipment rental transaction to generate an invoice onbehalf of the provider.

Further, in this specification, any references to sending ortransmitting a message, signal, etc. to another device (recipientdevice) means that the message is sent with the intention that itsinformation content ultimately be delivered to the recipient device;hence, such references do not mean that the message must be sentdirectly to the recipient device. That is, unless stated otherwise,there can be one or more intermediary entities that receive and forwardthe message/signal, either “as is” or in modified form, prior to itsdelivery to the recipient device. This clarification also applies to anyreferences herein to receiving a message/signal from another device;i.e., direct point-to-point communication is not required unless statedotherwise herein.

Additionally, references to “an embodiment”, “one embodiment” or thelike, mean that the particular feature, function, structure orcharacteristic being described is included in at least one embodiment ofthe invoice technology introduced here. Occurrences of such phrases inthe specification do not necessarily all refer to the same embodiment.On the other hand, the embodiments referred to also are not necessarilymutually exclusive.

FIG. 1 illustrates schematically a technique 100 for automaticidentification of an invoice. As illustrated in the embodiments of FIG.1 , the technique 100 involves communication between a computer system110 of a payment service (“payment service system 110” or “PSS 110”), apoint-of-sale (POS) computer system 120 (“POS system 120”) of a merchant122 (i.e., a POS merchant), and a POS computer system 130 (“POS system130”) of another merchant. An illustrative use case in reference to FIG.1 is now discussed to facilitate understanding of the technique 100. Theillustrative use case includes a transaction 140 and a transaction 150,conducted by a user 102 with two different merchants. The transaction140 will be discussed in further details in the description of FIG. 2 .

In the transaction 150, a user 102 makes a purchase with a merchant 122at the POS system 120. For example, the user 102 purchases a coffee anda breakfast sandwich at a “Bee Café” (i.e., merchant 122). The user 102can present a payment card 104 to the merchant 122 to pay for thepurchase. The payment card 104 can be a conventional credit card ordebit card, a proxy card that is associated with multiple financialaccounts, or an electronic card (e.g., a Europay, MasterCard, and Visa(EMV) card, an electronic card with Bluetooth Low Energy® (BLE), etc.)The merchant 122 (e.g., an employee) can swipe the payment card 104through a card reader 124 of the POS system 120, where the card reader124 reads payment card data from the payment card 104. The payment carddata can include, for example, a name, a card number, an expirationdate, a card verification code, among others.

The term “swipe” as used here refers to any manner of triggering aphysical card reader to read a physical card, such as passing a cardthrough a magnetic stripe reader, a smartcard reader, an optical codereader, radio frequency identification (RFID) reader, etc. In someembodiments, the payment card 104 is associated with a payment objectthat is physically used, in place of the payment card 104, to pay forthe purchase. In such embodiments, the card reader 124 can be an objectidentifier capable of reading data from the payment object, where a“swipe” refers to any manner of placing the payment object in a positionsuitable to be identified by the object identifier. For example, theobject identifier is a biometric finger scanner configured to obtaindata (e.g., fingerprint) related to a finger (i.e., a payment object)placed on the scanner, where the data is sufficient to enable initiationof payment authorization for the transaction. Furthermore, the term“sale,” as in point-of-sale (POS) or sales system, refers to any type ofpayment-oriented transaction, including a lease or rental for example,and is not limited to an actual purchase.

The POS system 120, via the card reader 124, obtains the payment carddata from the payment card 104 and transmits, via a wired or wirelesscommunications network, a message to the PSS 110. The message caninclude transaction data associated with the second transaction 150. Thetransaction data can include a transaction amount, the payment card data(such as the card number of the payment card 104), item-level dataassociated with the items purchased in the transaction 150, amongothers. The PSS 110, upon receiving the message from the POS system 120,can analyze the transaction data included in the message to identify acustomer involved in the transaction 150 (e.g., the user 102).

In some embodiments, the PSS 110 can identify the user 102 as thecustomer by searching the transaction data for a customer identifierassociated with the customer. The customer identifier can be the cardnumber of the payment card 104, the customer's email address, thecustomer's phone number, or any combination thereof stored by the PSS110, as discussed above. Upon identifying the customer identifier, thePSS 110 can identify any outstanding invoice(s) owed by the user 102based on stored association data related to the customer identifier. Inparticular, the PSS 110 can access a database associated with the PSS110 (e.g., via a Structured Query Language (SQL) query) to retrieve theassociation data. The association data specifies associations betweencustomer identifiers and corresponding invoices. The invoices caninclude, for example, an invoice generated for another transaction withthe merchant 122 (at the POS system 120 or another POS system associatedwith the merchant 122. The invoices can also include, for example, theinvoice generated for the first transaction 140, which will be discussedfurther below in reference to FIG. 2 .

In one example, the PSS 110 identifies the invoice by finding a matchbetween the card number (i.e., customer identifier) of the payment card104 used in the second transaction 150 and a card number of a particularpayment card stored in association with an invoice in the database. Inanother example, the PSS 110 identifies the invoice by finding a matchbetween a particular email address (i.e., customer identifier) providedby the user 102 in the transaction 150 and an email address stored inassociation with the invoice in the database. The particular emailaddress can be provided at the POS system 120, for example, when theuser 102 requests for an electronic receipt of the transaction 150. Inyet another example, the PSS 110 indirectly identifies the invoice byfirst finding a match between the card number of the payment card 104and a card number of a particular payment card stored in associationwith an email address in the database. The PSS 110 then proceeds to finda second match between that email address and a phone number stored inassociation with an invoice in the database, and identifies that invoiceto belong to the user 102. Alternatively, as another example, the PSS110 can proceed to find the invoice based on the invoice's associationwith the email address, which is stored in association with the paymentcard 104. Examples of the association data are illustrated in thedatabase tables 600, 602 of FIG. 6 .

Responsive to identification of a particular invoice, the PSS 110 cangenerate an invoice payment invitation for the user 102. The invoicepayment invitation operates as a notification to indicate that one ormore invoices have been identified for the user 102 based on thecustomer identifier associated with the user 102. The invoice paymentinvitation can include a promotion to provide an incentive to the user102 to pay the invoice. For example, the promotion includes a discountfor a transaction item associated with the merchant 122 (e.g., “Pay aninvoice to receive 20% off your next meal!”).

The invoice payment invitation can be generated at a display 126 of thePOS system 120. For example, the PSS 110 transmits the invoice paymentinvitation to an application executing at the POS system 120, andpresents the invoice payment invitation on the display 126. Theapplication (e.g., a payment service application) can receive theinvoice payment invitation via an Application Program Interface (API)associated with the PSS 110. Note that while one invoice paymentinvitation is discussed here for sake of simplicity, additional invoicepayment invitations may be generated based on the number of invoicesidentified for the user 102. In such instances, the merchant 122 and/orthe user 192, for example, can look through all of the invoice paymentinvitations to view all of the invoices by interacting with anotheraction button on the display 126 (e.g., “Next”). The merchant 122 and/orthe user 102 can also decide not to view the invoice paymentinvitation(s) by interacting with another action button on the display126 (e.g., “Skip”).

In some embodiments, in generating the invoice payment notification, thePSS 110 first determines whether the invoice identified is associatedwith the merchant 122 or a second, different merchant. In an event thatthe invoice is associated with a second merchant that is different fromthe merchant 122, the PSS 110 generates the invoice payment invitationto include limited information about the invoice (e.g., invoice amountor simply invoice merchant name). In this scenario, the merchant 122 cansimply notify the user 102 of the existence of the invoice and/or theinvoice amount, without revealing any other invoice details, such asitem-level transaction data about the product or service purchased,transaction date, billing address, among others.

In some embodiments, based on the determination that the invoice is notassociated with the merchant 122, the PSS 110 can transmit aconfirmation message to the POS system 120 for presentation at thedisplay 126. The confirmation message can prompt a passcode from theuser 102 to access the invoice details associated with the invoiceidentified. For example, the merchant 122 can interact with an actionbutton 128 (e.g., “Open”), which upon activation triggers presentationof the confirmation message prompting the passcode from the user 102.The merchant 122 can then rotate, or turn, the display 126 toward theuser 102 to allow input of the passcode. Responsive to input of a(correct) passcode, the invoice payment invitation can be fullypresented with the invoice details included for viewing by the user 102.In this way, the merchant 122 is prevented from viewing the invoicedetails, thereby protecting the privacy of the user 102.

The passcode inputted by the user 102 into the POS system 120 can betransmitted to the PSS 110 for verification. In some embodiments, thepasscode can be preconfigured, or specified, by the user 102 with thePSS 110. For example, the user 102 signs up for invoice service providedby the PSS 110. In some embodiments, the passcode can be any identifyingpiece of information about the user 102 that is stored by the PSS 110from a transaction and/or interaction (e.g., creation of user profilewith the PSS 110). In one example, the passcode is the birthday monthand date of the user 102 (e.g., 0315). In another example, the passcodeis a customer identifier (e.g., phone number).

In an event that the PSS 110 determines the invoice is associated withthe merchant 122, the PSS 110 generates the invoice payment invitationto include the invoice details. In some embodiments, the merchant 122can view those invoice details by interacting with the action button128. In such embodiments, the action button 128 can trigger display of aprompt requesting a merchant passcode. Responsive to input of a(correct) merchant passcode, the invoice payment invitation can be fullypresented with the invoice details included. In this way, the privacy ofthe user 102 is not violated by the merchant 122, which alreadypossesses knowledge of the invoice; furthermore, the privacy of the user102 is protected from unauthorized access (i.e., by a non-employee ofthe merchant 122).

In some embodiments, the invoice payment invitation can be generated andtransmitted for display at a user device 106 belonging to the user 102.In particular, the invoice payment invitation can be included in areceipt 108 generated for the transaction 150 conducted at the POSsystem 120. For example, the user 102 receives notification of theidentified invoice in the receipt for the transaction 150 aftercompletion of the transaction at the POS system 120 (e.g., payment cardauthorization and/or signature). In some embodiments, the receipt caninclude a link associated with the invoice payment notification wherethat link can be activated to pay the invoice. The link can direct theuser 102 to a network resource associated with the PSS 110 for makingthe payment. Activation of the link can be performed in a web browserexecuting on the user device 106. The PSS 110 can generate this link aspart of the invoice payment invitation that is included in the receiptsent to the user device 106.

In some embodiments, the PSS 110 generates and transmits the receipt tothe user device 106 using an email address submitted by the user 102 inthe second transaction 150. The email address can be submitted, forexample, in response to a request presented at the display 126 askingwhether the user 102 wishes to receive an electronic receipt for thetransaction 150. In such embodiments, the receipt 108 can be an emailmessage that includes the invoice payment invitation. Note that theemail address can also be the customer identifier used to identify theone or more invoices for the user 102 as discussed above.

In some embodiments, the PSS 110 generates and transmits the receipt tothe user device 106 using a phone number submitted by the user 102. Thephone number can be submitted, for example, in response to the requestasking whether the user 102 wishes to receive an electronic receipt. Insuch embodiments, the receipt 108 can be a text message that includesthe invoice payment invitation. Note that the phone number can also bethe customer identifier used to identify the one or more invoices forthe user 102 as discussed above.

The user device 106 can be any computing device capable of receivinguser input as well as transmitting and/or receiving data via a wired orwireless communications network. The user device 106 can be aconventional computer system (e.g., a desktop or a laptop computer) or amobile device having computer functionality (e.g., a tablet device, amobile telephone, or a smart-phone). An example of a user device 106 isa mobile computing device such as a tablet computer (e.g., an Apple®iPad®) or a smartphone (e.g., an Apple® iPhone®).

Upon receiving the invoice payment invitation (e.g., either via the POSsystem 120 or the user device 106), the user 102 can submit a paymentfor the invoice. For example, at the POS system 120, the user 102interacts with an action button (e.g., “Pay”) on the display 126 tosubmit the payment. In another example, the user 102 activates the linkincluded in the receipt (as discussed above). In some embodiments,activation of the link triggers a web browser executing on the userdevice 106 to generate a web page at which the user 102 can submit theinvoice payment. In other embodiments, activation of the link results inan authorization of the payment card 104 to be charged for the invoicepayment.

In some embodiments, the PSS 110 receives an indication of the linkactivation by the user 102 using the user device 106. The indication ofthe activation can include invoice payment data, or information, thatindicates the payment is submitted for a particular invoice. In someembodiments, the invoice payment data can include the payment card dataassociated with the payment card 104 charged with the invoice payment.Upon receiving the indication of the activation, the PSS 110 can triggerfunds to be transferred from an account associated with the user 102 tothe invoice merchant associated with the paid invoice. In someembodiments, the PSS 110 communicates with a credit card network totransfer the funds. In other embodiments, the PSS 110 communicates witha debit card network to transfer the funds. In some embodiments, the PSS110 also transmits a confirmation message of the invoice payment to theinvoice merchant.

FIG. 2 illustrates schematically a technique 200 of generating aninvoice and identifying one or more merchants at which to pay theinvoice. An illustrative use case is discussed in reference to thetransaction 140 of FIG. 2 for ease of understanding of the technique200. The transaction 140 can take place before the transaction 150discussed in FIG. 1 . For example, the transaction 140 can occur a fewhours or a few days before transaction 150.

In the transaction 140, the user 102 makes a purchase of a product orservice with a merchant at the POS system 130. The merchant can be adifferent merchant from the merchant 122. For example, the merchant is afitness club merchant offering a gym membership service, whereas themerchant 122 is a café merchant. In the illustrative use case, thetransaction 140 includes a business agreement that allows the user 102to defer payment through use of an invoice (e.g., invoice 114) providedby the merchant (i.e., invoice merchant), as opposed to immediatepayment.

In particular, the user 102 provides information to the invoice merchantfor generating the invoice, where that information is inputted into thePOS system 130. The information can include a customer name, a customeraddress (e.g., billing address and/or mailing address), and transactiondata about the transaction 140, such as item-level data, transactionamount, among others. In some embodiments, the transaction data can alsoinclude one or more customer identifiers of the user 102. In oneexample, the customer identifier is an email address of the user 102(e.g., provided by the user 102 to receive the invoice in an emailmessage). In another example, the customer identifier is a phone numberof the user 102 (e.g., provided by the user 102 to receive the invoicein a text message). In yet another example, the customer identifier is abiometric identifier (e.g., a fingerprint inputted to the POS system 130by the user 102 as part of an authorization process).

In some embodiments, the POS system 130 can generate the invoice for thetransaction 140 using the information that includes the transactiondata. Alternatively, in some embodiments, the POS system 130 transmitsthat information to the PSS 110 in a request to generate the invoice forthe transaction 140 for the user 102. In such embodiments, the POSsystem 130 can also transmit a card number of the payment card 104 asanother customer identifier for use in generating the invoice. Thepayment card 104 can be already on file with the invoice merchant (e.g.,a customer profile stored at the POS system 130), where the payment card104 has been used in a past transaction conducted with the merchantand/or at the POS system 130; the merchant, however, may not haveauthorization to charge the payment card 104 for any subsequenttransaction, such as the transaction 140.

Upon receiving the request from the POS system 130, the PSS 110communicates with an invoice system 112, which generates an invoice 114for the transaction 140. The invoice system 112 can be an applicationexecuting on the PSS 110, where the application can be software,hardware, or a combination thereof. In some embodiments, the invoicesystem 112 and the PSS 110 can be implemented in the same computingdevice, such as a smart phone or a tablet computer, so that thestandalone computing device can be the sole host and practice thevarious techniques disclosed herein. In some embodiments, the PSS 110 isthe invoice system 112. In other embodiments, the invoice system 112 canbe a separate entity from the PSS 110. In some embodiments, the invoicemerchant can input the request for invoice directly into the invoicesystem 112. In such embodiments, the invoice system 112 can be, forexample, an application executing on a computing device, which can bethe POS system 130. The application, in this example, can communicatewith the PSS 110 via an Application Program Interface (API).

The invoice system 112 generates the invoice 114 by incorporating theinformation received from the POS system 130, the PSS 110, and/ordirectly from the invoice merchant. In particular, the invoice system112 generates the invoice 114 by including the transaction data in theinvoice 114. The invoice system 112 can also determine and generate alist of one or more merchants to include in the invoice 114. The one ormore merchants are recommended merchants with which the user 102 canmake payment for the invoice 114. The invoice system 112 can determinethe list of merchants based on a spending trend of the user 102, pasttransactions of the user 102, a geographical location of the user 102,and/or a combination thereof. For example, the list can include aboutique clothing store identified based on a spending trend of the user102, a café (e.g., the merchant 122) identified based on a pasttransaction conducted at the POS system 120 (e.g., the user 102 is aregular customer at Bee Café), and another merchant located within 5miles of an address associated with the user 102 (e.g., mailingaddress).

The merchant(s) identified based on a geographical location can belocated within a specified distance of the address associated with theuser 102. The specified distance can be configured, or specified, by theinvoice system 112. In some embodiments, the specified distance can bespecified by the identified merchants themselves. For example, theidentified merchants can submit a request to the PSS 110 to be placed inany invoice(s) of customers that are located within 5 miles of thesemerchants. In some embodiments, the specified distance can be specifiedby the invoice merchant. For example, the invoice merchant (e.g.,fitness club) can submit request to the PSS 110 that only specificmerchants with whom the invoice merchant have a special businessrelationship and/or offer complementary services or products (e.g.,fitness equipment) are to be included in the invoice(s).

Upon completion, the invoice system 112 transmits the generated invoice114 back to the PSS 110 for transmission to the POS system 130.Alternatively, the invoice system 112 can directly transmit thegenerated invoice 114 to the POS system 130. In some embodiments, wherethe invoice system 112 is executing on the POS system 130, the invoice114 is displayed at the POS system 130.

The POS system 130, upon receiving the invoice 114, can present it tothe user 102 in numerous ways. For example, the POS system 130 causes aphysical copy of the invoice 114 to be printed out for the user 102. Inanother example, the POS system 130 presents a “virtual” copy of theinvoice 114 on the display 126 of the POS system 130. In someembodiments, the POS system 130 can present it to the user 102 throughan electronic message. For example the POS system 130 prompts the user102 whether he/she wishes to receive an electronic copy of the invoice114, and requests an electronic address (e.g., an email address or aphone number) for transmission of such copy. Upon receiving thatelectronic address, the POS system 130 can cause the invoice to betransmitted to the user 102 for viewing at the user device 106.

In some embodiments, the POS system 130 itself transmits the invoice 114responsive to receiving the electronic address. In other embodiments,the POS system 130 forwards the received electronic address to theinvoice system 112, which transmits the generated invoice 114 to theuser device 106. For example, the invoice 114 can be transmitted as anemail message or a text message using an email address or phone number(i.e., electronic addresses). In some embodiments, the invoice system112 can also transmit the invoice 114 to the user device 106 using theemail address and/or the phone number submitted for creating the invoice114 (as discussed above). For example, the invoice 114 is transmitted asan email message to an email account of the user 102.

In some embodiments, the invoice system 112 transmits the generatedinvoice 114 to the PSS 110. The PSS 110 can store the generated invoice114 in association with one or more customer identifiers of the user102. The customer identifiers can be those submitted to the POS system130 and/or the invoice system 112 in the request to generate an invoice.The association between the customer identifier(s) and the invoice 114can be stored in a database associated with the PSS 110.

In one example, the PSS 110 stores the phone number of the user 102 inassociation with the invoice 114, and further stores that phone numberin association with the email address. In another example, the PSS 110stores the email address of the user 102 in association with the invoice114, and further stores that email address in association with the cardnumber of the payment card 104. In yet another example, the PSS 110stores the card number of the payment card 104 in association with theinvoice 114. As discussed above in reference to FIG. 1 , the one or morestored associations can be used for identification of any invoice(s)associated with a particular consumer, where the particular customer canbe automatically notified of the identified invoice(s) when conducting atransaction (e.g., transaction 150) with a POS merchant at a POS systemassociated with the PSS 110. The POS merchant can be the same merchant(i.e., the invoice merchant) using the same POS system (e.g., POS system130) or a different POS system. The POS merchant can also be adifferent, second merchant (e.g., merchant 122) using a different POSsystem (e.g., POS system 120).

FIGS. 3A-3B are example graphical user interfaces generated by amerchant POS system based on the invoice technology. In someembodiments, the GUIs can be generated by the POS system 120 of FIG. 1 .In some embodiments, the GUIs can be generated by the GUI generationmodule 512 of FIG. 5 . FIG. 3A illustrates an example GUI 300 promptinga customer to input a phone number 302 or an email address 304 at whichto receive an electronic receipt for a transaction conducted at themerchant POS system. The phone number 302 and the email address 304 caneach be stored as a customer identifier of the customer for use in othertransactions.

FIG. 3B illustrates an example GUI 310 notifying the customer of twoinvoices 312, 314 that have been identified for the customer. Theseinvoices 312, 314 can be identified based on the phone number 302 and/orthe email address 304 inputted in GUI 300. In some embodiments, theinvoices 312, 314 can also be identified based on payment card datareceived in the transaction with the customer. The customer can chooseto authorize payment for a particular invoice by interacting (e.g.,click or touch) with an action button included in the GUI 310 (e.g.,“Pay & Claim Promo” action button). For example, the customer can payfor the invoice with “Store X” and receive a free meal at Bee Café inexchange for that payment.

FIGS. 4A-4B are example graphical user interfaces generated by a userdevice based on automatic invoice identification in accordance withvarious embodiments of the disclosed technology. In some embodiments,the GUIs can be generated by the user device 106 of FIG. 1 or 2 . Insome embodiments, the GUIs can be generated by the GUI generation module512 of FIG. 5 . FIG. 4A illustrates an example GUI 400 showing anelectronic receipt in the form of an application executing on a mobilecomputing device of a customer. The electronic receipt can betransmitted to the application via an API associated with a receiptgeneration system. The receipt generation system can be a part of, orassociated with, the PSS. The customer can pay for an identified invoiceincluded in the receipt by interacting with an action link 402. FIG. 4Billustrates an example GUI 410 showing an electronic receipt in the formof an email message generated by an email application executing on themobile computing device of the customer. The email message has beentransmitted (e.g., by a receipt generation system, which can be a partof, or associated with, the PSS) to an email account of the customer,and can be displayed by the email application for viewing at the mobilecomputing device. The customer can pay for the identified invoiceincluded in the receipt by interacting with an action link 412 includedin the email message.

FIG. 5 illustrates various components of a payment service system 500that can be utilized in various embodiments of the invoice technology.In some embodiments, the payment service system 500 can be the PSS 110of FIG. 1 . As illustrated in FIG. 5 , the payment service system 500can include one or more processors 502, memory 504, an invoicegeneration module 506, an invoice management module 508, a financialmodule 510, and a graphical user interface (GUI) generation module 512.Other embodiments of the invoice technology can include some, all, ornone of these modules and components along with other modules,applications, and/or components. Still yet, some embodiments canincorporate two or more of these modules and components into a singlemodule and/or associate a portion of the functionality of one or more ofthese modules with a different module. For example, in some embodiments,the invoice generation module 506 and the invoice management module 508can be combined into a single component for generating an invoice andidentifying invoice(s) associated with a user.

The memory 504 can be any device, mechanism, or populated data structureused for storing information. In some embodiments of the invoicetechnology, the memory 504 can be or include any type of, but is notlimited to, volatile memory, nonvolatile memory and dynamic memory. Thememory 504 can be or include one or more disk drives, flash drives, oneor more databases, and/or the like. The memory 504 can also include oneor more tables, one or more files, local cache memories, processor cachememories, relational databases, and/or the like. In some embodiments,the memory 504 can be used to store instructions for executing, orrunning, one or more applications or modules on the processor(s) 502.For example, the memory 504 could be used in various embodiments tohouse all or some of the instructions needed to execute thefunctionality of the invoice generation module 506 and/or the invoicemanagement module 508.

The invoice generation module 506 is coupled to the processor(s) 502 andconfigured to receive, from a merchant point-of-sale (POS) system, arequest to generate an invoice for a particular transaction. Theparticular transaction can be initiated at the merchant POS systembetween a customer (e.g., user 102 of FIG. 1 ) and a first merchant. Therequest to generate the invoice can include a particular customeridentifier associated with the customer. As discussed above, theparticular customer identifier can include, for example, an emailaddress, a telephone number, a payment card number, or any combinationthereof.

In some embodiments, the request to generate the invoice can besubmitted to the merchant POS system via an invoice system (e.g.,invoice system 112 of FIG. 2 ) in the form of an application executingon the merchant POS system, where the application communicates with aPSS (e.g., PSS 110 of FIG. 1 ) via an API. In other embodiments, therequest to generate the invoice can be submitted via the invoice systemin the form of a website that is accessible by a web browser executingon a computing device of a user merchant (e.g., a smart-phone). Thewebsite is associated with the PSS and is operatively coupled tocommunicate with the PSS via a wireless or wired communications network.In yet other embodiments, the request to generate the invoice can besubmitted via a customized client executing on the computing device ofthe user merchant. The customized client can communicate with the PSSvia a wired or wireless communications network using an API.Alternatively, the customized client and the PSS can be implemented inthe same computing device.

The invoice generation module 506 is configured to access, based on thecustomer identifier included in the request for invoice, firstassociation data to identify a set of one or more transactions that areassociated with the particular customer identifier. In particular, thefirst association data specifies a first set of associations betweencustomer identifiers of all users of the computer system 500 and allcorresponding transactions conducted by those users. Accessing the firstassociation data to identify the set of transactions can includeperforming a search (e.g., SQL query) in a database for anytransaction(s) that are associated with the particular customeridentifier.

The invoice generation module 506 is configured to identify, based onthe set of transactions associated with the particular customeridentifier, a set of one or more merchants that correspond to that setof transactions. The set of merchants are those merchants at which thecustomer (identified based on the particular customer identifier) hasconducted transactions in the past. In some embodiments, the merchantsidentified in the set can be filtered based on a frequency of visits(e.g., a number of transactions), a recentness of visits (e.g.,transactions conducted within the last week), or a combination thereof(e.g., number of transactions within the last week). In someembodiments, the merchants identified in the set can be further filteredbased on a number of merchants to be included. For example, Bee Café andCorner Laundromat are the top two merchants at which the customer hasconducted the largest number of transactions in the last week, areidentified for the set of merchants.

Using the identified set of merchants, the invoice generation module 506is configured to generate the invoice for the particular transactioninitiated at the POS system, as requested. In particular, the invoicegeneration module 506 generates an invoice that includes arecommendation of the identified set of merchants to notify the customerthat the generated invoice can be paid at these merchants. In someembodiments, the invoice generation module 506 is configured to store,in a database, the generated invoice in association with the particularcustomer identifier of the customer (e.g., transmitting to a databaseserver and/or storing at a local database). Such storing of the invoicein association with the particular customer identifier can enableidentification of the invoice in a later transaction at which the samecustomer (i.e., same particular customer identifier) conducts with themerchant and/or a different merchant.

The invoice management module 508 is coupled to the processor(s) 502 andis configured to receive transaction data from a merchant POS system foranother transaction (“second transaction”) initiated at the merchant POSsystem (“second POS system”). The second POS system can be the same POSsystem discussed above in reference to the invoice generation module506, or a different POS system. For example, the second POS system is aPOS system of the same merchant (as discussed in reference to theinvoice generation module 506), but is located at a different businesslocation of the merchant. In another example, the second POS system is aPOS system of a different merchant; for example, the merchant discussedhere can be the Corner Laundromat and the other merchant discussed inreference to the invoice generation module 506 is a fitness club.

The transaction data received from the second POS system can include acustomer identifier that is the same as the particular customeridentifier that identifies the same customer discussed above. Uponreceiving this customer identifier, the invoice management module 508 isconfigured to access a database to find second association data foridentifying any invoice(s) that are associated with the customeridentifier. In particular, the second association data specifies asecond set of associations between customer identifiers of all users ofthe computer system 500 and all corresponding invoices. For example, onecustomer identifier is associated with three invoices. In anotherexample, another customer identifier is associated with only oneinvoice. Accessing the second association data to identify theinvoice(s) can include performing a search (e.g., SQL query) in adatabase for any invoice(s) that are associated with the customeridentifier in the transaction data associated with the secondtransaction. The invoice management module 508, for example, identifiesthe invoice generated by the invoice generation module 506 discussedabove.

Upon finding an invoice, the invoice management module 508 is configuredto generate an invoice payment invitation for that invoice. The invoicepayment invitation can include a promotion to provide an incentive tothe customer to pay the invoice. The promotion can include a discountfor a transaction item available for purchase from the merchantassociated with the second POS system. For example, the promotion is a30% discount for laundry service in exchange for payment of the invoiceof membership fee with the fitness club.

In some embodiments, the invoice management module 508 is configured toreceive, from the second POS system, invoice payment information thatindicates a payment for the invoice has been authorized at the secondPOS system. The invoice payment can be paid via authorization by thecustomer at the second POS system. An example of a GUI illustrating anoption for the customer to pay the invoice (and claim an associatedpromotion) is shown in FIG. 3B. As discussed above, the invoice paymentinvitation can be displayed (or output in another manner) at the secondPOS system, or at a computing device of the customer. Accordingly, theinvoice payment can be paid using either the second POS system or thecomputing device of the customer.

In some embodiments, the invoice management module 508 is configured totransmit a notification of the invoice payment to the POS system of theinvoice merchant (e.g., the first POS system discussed above inreference to the invoice generation module 506. The invoice managementmodule 508 can also be configured to transmit the notification of theinvoice payment to a computing device of the customer.

The financial module 510 can be used to track financial transactions.For example, in some embodiments, the PSS 110 (FIG. 1 ) facilitates thetransfer of funds between various merchants using the invoicetechnology. For example, the PSS 110 ensures that compensationpayment(s) from an invoice merchant to a participating merchant (i.e.,the merchant providing the promotion to provide an incentive to invoicepayment(s)) are properly deducted and credited. In other embodiments,the financial module 510 charges a fee from the various merchants forutilizing the invoice technology. In yet other embodiments, thefinancial module 510 processes payments (i.e., funds transfers) fortransactions conducted by the various merchants with their respectivecustomers. For example, the financial module 510 ensures that creditcards are properly charged for services and/or goods provided by themerchants to their respective customers.

The GUI generation module 512 generates one or more GUI screens thatenable interaction with a user of the computer system 500. In someembodiments, GUI generation module 512 generates a GUI screen enabling auser of the computer system 500 to set preferences, authenticationstandards, and/or passcodes, set rules, set constraints, customizemessages, and/or otherwise receive or convey information to the user.For example, the GUI generation module 512 generates a GUI that enablesan operator of the PSS 110 (FIG. 1 ) to configure the type of merchantsthat are identified for inclusion in an invoice.

In some embodiments, GUI generation module 512 generates a GUI screenenabling a user of the computer system 500 to interact with the computersystem 500 for executing various functionalities. For example, the GUIgeneration module 512 generates one or more GUIs for display within aninvoice application (e.g., invoice system 112 of FIG. 2 ) executing on acomputing device. In another example, the GUI generation module 512generates one or more GUIs for display within an application (e.g., apayment service application) executing on the POS system 120 (FIG. 1 )for processing payments. An example of such a GUI is shown in FIG. 3Afor prompting a customer how he/she would like to receive a receipt fora transaction executed at a POS system. Another example of such a GUI isshown in FIG. 3B for inviting a customer to pay an invoice and claim apromotion associated with that invoice payment.

The database 514 is configured to maintain data for facilitating theprocessing of invoices and/or transactions and/or other functionalitiesof the computer system 500. The data can include, for example,transaction data, information related to invoices, financial accountdata (e.g., credit card or debit card numbers), user account data (e.g.,email addresses, phone numbers, addresses, biometric information, etc.),or the like. The data can be stored in association with one another inthe database 514, which can be, for example, a relational database. Thedatabase 514 can include, for example, one or more hard drives (whichmay be further coupled together using RAID-0, 1, 5, 10, etc.), acentralized or distributed data cluster, a cloud-storage serviceprovider, or other suitable storage systems suitable for storing digitaldata.

FIG. 6 illustrates example database tables that can be utilized with theinvoice technology. The embodiments of FIG. 6 includes an exampledatabase table 600 and an example database table 602, both of which canbe stored in the database 514 (FIG. 5 ). The database table 600 caninclude various fields of data, or information, such as, but not limitedto: customer ID1 (e.g., invoice record number or name); customer ID2(e.g., email address); customer ID3 (e.g., phone number); first name;last name; billing address; and/or the like. The database table 602 caninclude various fields of data, or information, such as, but not limitedto: customer ID2 (e.g., email address), customer ID4 (e.g., credit ordebit card number), or a combination thereof; card issuer; cardexpiration date; billing address; and/or the like.

FIG. 7 is a flowchart illustrating a set of operations 700 forgenerating an invoice with recommended merchants for paying the invoice.In some embodiments, the set of operations 700 can be executed by thePSS. In other embodiments, the set of operations 700 can be executed byin invoice system executing on a POS system, where the invoice systemcommunicates with the PSS via an API. In yet other embodiments, the POSsystem can be a mobile computing device, such as a smart-phone or atablet.

At operation 702, a request is received to generate an invoice between acustomer and a merchant (i.e., invoice merchant). The request can bereceived from a merchant POS system. The request can include transactioninformation associated with the transaction between the customer and theinvoice merchant. The transaction information can include, for example,customer information (e.g., billing address, shipping address, serviceaddress such as where the customer lives and uses the purchased service,customer name, customer identifiers such as phone number or emailaddress, etc.), transaction amount, item-level transaction data (e.g.,information about item description, price, quantity, etc.), invoicepayment due date, among others. In some embodiments, payment cardinformation (including a card number) is also received in the request togenerate the invoice.

At operation 704, one or more merchants are identified asrecommendations at which the customer to pay the invoice. Themerchant(s) can be identified based on past transactions conducted bythe customer, spending trend of the customer, and/or a geographicallocation associated with the customer. For example, a merchantgeographically located within a specified distance from a billingaddress of the customer is identified. In another example, a merchantgeographically located within a specified distance from a serviceaddress at which the service is rendered for the customer is identified.In yet another example, a merchant geographically located within aspecified distance from the invoice merchant itself is identified.

In some embodiments, the merchants identified can also be filtered basedon various criteria. The various criteria can include, for example, amaximum number of merchants, a frequency of visits by the customer, arecentness of visits by the customer. In some embodiments, the merchantsidentified can be prioritized based on a business relationship with thesystem. For example, merchant X engages in a business relationship topay a fee for being listed on all invoices generated for customers, as aform of advertisement to encourage customers to visit merchant X. All ofthe identified merchants are then generated as a list for inclusion inthe invoice to be generated.

At operation 706, the invoice is generated to include the list of one ormore merchants and at least some of the transaction data received in therequest for invoice. For example, the invoice includes item-level dataassociated with the service or product purchased in the transaction, andtwo merchants located within 5 miles from the invoice merchant. Thegenerated invoice can be transmitted to the POS system of the invoicemerchant for printing, displayed electronically at the POS system, ortransmitted electronically for viewing by the customer.

At operation 708, the generated invoice is stored in association with acustomer identifier of the customer. The customer identifier can be partof the customer information received in the request for invoice. Thecustomer identifier can be, for example, a phone number or an emailaddress. As discussed above in reference to FIG. 1 , the storedassociation can be used for identification of the generated invoice toautomatically notify the customer whenever he/she conducts anothertransaction with a POS merchant at a POS system associated with the PSS110. The POS merchant can be the same merchant (i.e., the invoicemerchant) using the same POS system or a different POS system. The POSmerchant can also be a different, second merchant (e.g., merchant 122)using a different POS system (e.g., POS system 120).

FIG. 8 is a flowchart illustrating a set of operations 800 foridentification and notification of invoice(s) based on receivedtransaction data. In some embodiments, the set of operations 800 can beexecuted by the PSS.

At operation 802, transaction data is received from a POS systemassociated with a POS merchant for a transaction between the POSmerchant and a customer. The transaction data can include a card numberfor the transaction, where the card number is an identifier associatedwith the customer. In some embodiments, the transaction data can alsoinclude another identifier associated with the customer, such as anemail address or a phone number. In such embodiments, the email addressor phone number can be received as part of a receipt delivery process,where the email address or phone number is an electronic addressprovided by the customer for receiving the receipt for the transactionwith the POS merchant.

At operation 804, a database is accessed to retrieve association datarelating to the card number included in the transaction data receivedfrom the POS system. At operation 806, an invoice associated with thecard number is identified using the association data retrieved from thedatabase. In particular, the invoice is identified by correlating thecard number with an identifier and correlating that identifier with oneor more invoice(s). In one example, an invoice is identified by findinga match between the card number (included in the transaction data) and acard number of a particular payment card that stored in association withan invoice. In another example, the invoice is identified based on theinvoice's association with the email address, which is stored inassociation with the card number.

At operation 808, an invoice payment invitation is generated based onthe identified invoice. Generating the invoice payment invitation caninclude generating a promotion for inclusion in the invoice paymentinvitation to provide an incentive to the customer to pay the invoice.The promotion can be preconfigured, or specified, by the POS merchantinvolved in the transaction of FIG. 8 . For example, the POS merchantspecifies that the promotion is to be offered for inventory items thatare slow to sell and/or in excess in order to improve business. Inanother example, the POS merchant specifies that the promotion is to beoffered for discounts associated with particular days of the week and/ortimes of the day that experience low customer visits. In yet anotherexample, the POS merchant specifies that the promotion has a maximumpromotional value (e.g., available only for $5 items or $50 items, ormaximum discount of $10 off). As discussed above, the payment invoiceinvitation can be displayed at the POS system or at a user devicebelonging to the customer.

At operation 810, invoice payment information is received to indicatethat an invoice payment has been submitted by the customer. At operation812, a message is transmitted to the invoice merchant to notify theinvoice merchant of the invoice payment (e.g., POS system associatedwith the invoice or another computing device associated with the invoicemerchant). At operation 814, funds are caused to be transferred from theinvoice merchant to the POS merchant as a compensation payment (e.g.,reimbursement) for the POS merchant in exchange for the invoice paymentreceived. In some embodiments, causing the funds to be transfer caninclude communicating with card payment networks (e.g., credit card ordebit card payment networks) of the corresponding merchants to requestfor funds transfer.

Regarding the sets of operations 700 and 800, while the various steps,blocks or sub-processes are presented in a given order, alternativeembodiments can perform routines having steps, or employ systems havingsteps, blocks or sub-processes, in a different order, and some steps,sub-processes or blocks can be deleted, moved, added, subdivided,combined, and/or modified to provide alternative or sub-combinations.Each of these steps, blocks or sub-processes can be implemented in avariety of different ways. Also, while steps, sub-processes or blocksare at times shown as being performed in series, some steps,sub-processes or blocks can instead be performed in parallel, or can beperformed at different times as will be recognized by a person ofordinary skill in the art. Further any specific numbers noted herein areonly examples; alternative implementations can employ differing valuesor ranges.

FIG. 9 illustrates an example of a processing computer system 900 thatcan be used to implement any of the computing devices referred to above,such as a user device, the POS system, the PSS, etc. Any of thesedevices each can include multiple instances of an architecture such asshown in FIG. 9 (i.e., multiple computers), particularly server-basedsystems, and such multiple instances can be coupled to each other viaone or more networks.

In the illustrated embodiments of FIG. 9 , the processing system 900includes one or more processors 902, memory 904, one or morecommunication device(s) 906, one or more input/output (I/O) devices 908,and one or more mass storage devices 910, all of which are coupled toone another through an interconnect 912. The interconnect 912 may be orinclude one or more buses, point-to-point connections, controllers,adapters and/or other conventional connection devices.

The processor(s) 902 can be or include, for example, one or moregeneral-purpose programmable microprocessors, digital signal processors(DSPs), microcontrollers, application specific integrated circuits(ASICs), programmable gate arrays, or the like, or a combination of suchdevices. The processor(s) 902 control the overall operation of theprocessing device 900.

Memory 904 can be or include one or more physical storage devices, whichmay be in the form of random access memory (RAM), read-only memory (ROM)(which may be erasable and programmable), flash memory, miniature harddisk drive, or other suitable type of storage device, or a combinationof such devices. The mass storage device (s) 910 may be or include oneor more hard drives, digital versatile disks (DVDs), flash memories, orthe like. The memory 904 and/or the mass storage device(s) 910 can store(individually or collectively) data and instructions that configure theprocessor(s) 902 to execute operations in accordance with the techniquesdescribed above.

The communication devices 906 can be or include, for example, anEthernet adapter, cable modem, Wi-Fi adapter, cellular transceiver,Bluetooth or Bluetooth Low Energy (BLE) transceiver, or the like, or acombination thereof. For example, in the case of a client device, thecommunication devices 906 can be or include, for example, a cellulartelecommunications transceiver (e.g., 3G or 4G/LTE), Wi-Fi transceiver,Bluetooth or BLE transceiver, or the like, or a combination thereof.

Depending on the specific nature and purpose of the processing device900, the I/O devices 908 can include devices such as a display (whichmay be a touch screen display), audio speaker, keyboard, mouse or otherpointing device, microphone, camera, etc. Note that these I/O devicesmay be unnecessary, however, if the processing device 900 is embodiedsolely as a server computer.

Unless contrary to physical possibility, it is envisioned that (i) themethods/steps described herein may be performed in any sequence and/orin any combination, and that (ii) the components of respectiveembodiments may be combined in any manner.

The machine-implemented operations described above can be implemented byprogrammable circuitry programmed/configured by software and/orfirmware, or entirely by special-purpose circuitry, or by a combinationof such forms. Such special-purpose circuitry (if any) can be in theform of, for example, one or more application-specific integratedcircuits (ASICs), programmable logic devices (PLDs), field-programmablegate arrays (FPGAs), etc.

Software used to implement the techniques introduced here may be storedon a machine-readable storage medium and may be executed by one or moregeneral-purpose or special-purpose programmable microprocessors. A“machine-readable medium”, as the term is used herein, includes anymechanism that can store information in a form accessible by a machine(a machine may be, for example, a computer, network device, cellularphone, personal digital assistant (PDA), manufacturing tool, any devicewith one or more processors, etc.). For example, a machine-accessiblemedium includes recordable/non-recordable media (e.g., read-only memory(ROM); random access memory (RAM); magnetic disk storage media; opticalstorage media; flash memory devices; etc.), etc.

1.-20. (canceled)
 21. A method comprising: transmitting, from a merchantpoint-of-sale (POS) device of a first merchant and to one or moreservers of a payment processing service, transaction data for atransaction occurring at the merchant POS device between a customer andthe first merchant, the transaction data including a customeridentifier; receiving, by the merchant POS device and from the one ormore servers of the payment processing service, data associated with anunpaid invoice associated with the customer identifier and a historicaltransaction between the customer and the first merchant or a secondmerchant; and based at least in part on the data associated with theunpaid invoice, causing presentation, by the merchant POS device and ona display of the merchant POS device, an invoice payment invitation forthe customer to make a payment on the unpaid invoice.
 22. The method ofclaim 21, wherein the merchant POS device comprises a first merchant POSdevice, and wherein the historical transaction occurs at the firstmerchant POS device or a second merchant POS device of the secondmerchant.
 23. The method of claim 21, wherein the unpaid invoice isobtained from a database associated with the one or more servers of thepayment processing service.
 24. The method of claim 21, furthercomprising: receiving, at the merchant POS device and responsive atleast in part to causing presentation of the invoice payment invitation,input comprising invoice payment information associated with the paymentof the unpaid invoice; and responsive at least in part to receiving theinvoice payment information, transmitting, by the merchant POS device,the invoice payment information to the one or more servers.
 25. Themethod of claim 21, wherein the unpaid invoice comprises a first unpaidinvoice, wherein the merchant POS device comprises a first merchant POSdevice, wherein the transaction data comprises first transaction data,the payment comprises a first payment, and the method furthercomprising: sending, by the first merchant POS device to the one or moreservers, second transaction data associated with a second unpaid invoicefor a second transaction occurring at the first merchant POS devicebetween a second customer and the first merchant, the second transactiondata including a second customer identifier of the second customer; andresponsive at least in part to sending the second transaction data,receiving, by the first merchant POS device and from the one or moreservers, an indication of a second payment on the second unpaid invoice,wherein the second payment is made via a second merchant POS device ofthe second merchant or a third POS device of a third merchant.
 26. Themethod of claim 21, wherein the invoice payment invitation includes alink, that upon activation, enables the customer to make the payment onthe unpaid invoice.
 27. The method of claim 21, wherein the invoicepayment invitation includes an indication of an incentive available tothe customer upon the customer making the payment on the unpaid invoice,wherein the incentive includes a discount for a transaction itemassociated with the transaction.
 28. The method of claim 21, whereincausing presentation of the invoice payment invitation comprises causingpresentation of at least one of an image of the unpaid invoice orinformation from the unpaid invoice.
 29. The method of claim 21, whereinthe customer identifier is one or more of an email address, a phonenumber, or a card number of a payment card associated with the customer.30. The method of claim 21, wherein transmitting the transaction datafrom the merchant POS device comprises transmitting the transaction datafrom a merchant support application executing on the merchant POSdevice, wherein the merchant support application is provided by thepayment processing service.
 31. The method of claim 21, furthercomprising: causing presentation, by the merchant POS device on thedisplay of the merchant POS device, a request for a passcode from thecustomer for accessing invoice details associated with the unpaidinvoice; and responsive to receiving the passcode, causing presentation,by the merchant POS device, of the invoice payment invitation, whereinthe invoice payment invitation includes the invoice details.
 32. Asystem comprising: one or more processors; and one or morenon-transitory computer-readable media storing instructions executableby the one or more processors, wherein the instructions cause the one ormore processors to perform acts comprising: transmitting, from amerchant point-of-sale (POS) device of a first merchant and to one ormore servers of a payment processing service, transaction data for atransaction occurring at the merchant POS device between a customer andthe first merchant, the transaction data including a customeridentifier; receiving, by the merchant POS device and from the one ormore servers of the payment processing service, data associated with anunpaid invoice associated with the customer identifier and a historicaltransaction between the customer and the first merchant or a secondmerchant; and based at least in part on the data associated with theunpaid invoice, causing presentation, by the merchant POS device and ona display of the merchant POS device, an invoice payment invitation forthe customer to make a payment on the unpaid invoice.
 33. The system ofclaim 32, wherein the merchant POS device comprises a first merchant POSdevice, and wherein the historical transaction occurs at the firstmerchant POS device or a second merchant POS device of the secondmerchant.
 34. The system of claim 32, wherein the unpaid invoice isobtained from a database associated with the one or more servers of thepayment processing service.
 35. The system of claim 32, the acts furthercomprising: receiving, at the merchant POS device and responsive atleast in part to causing presentation of the invoice payment invitation,input comprising invoice payment information associated with the paymentof the unpaid invoice; and responsive at least in part to receiving theinvoice payment information, transmitting, by the merchant POS device,the invoice payment information to the one or more servers.
 36. Thesystem of claim 32, wherein the unpaid invoice comprises a first unpaidinvoice, wherein the merchant POS device comprises a first merchant POSdevice, wherein the transaction data comprises first transaction data,the payment comprises a first payment, and the acts further comprising:sending, by the first merchant POS device to the one or more servers,second transaction data associated with a second unpaid invoice for asecond transaction occurring at the first merchant POS device between asecond customer and the first merchant, the second transaction dataincluding a second customer identifier of the second customer; andresponsive at least in part to sending the second transaction data,receiving, by the first merchant POS device and from the one or moreservers, an indication of a second payment on the second unpaid invoice,wherein the second payment is made via a second merchant POS device ofthe second merchant or a third POS device of a third merchant.
 37. Thesystem of claim 32, wherein the invoice payment invitation includes alink, that upon activation, enables the customer to make the payment onthe unpaid invoice.
 38. One or more non-transitory computer-readablemedia storing instructions executable by one or more processors that,when executed by the one or more processors, cause the one or moreprocessors to perform acts comprising: transmitting, from a merchantpoint-of-sale (POS) device of a first merchant and to one or moreservers of a payment processing service, transaction data for atransaction occurring at the merchant POS device between a customer andthe first merchant, the transaction data including a customeridentifier; receiving, by the merchant POS device and from the one ormore servers of the payment processing service, data associated with anunpaid invoice associated with the customer identifier and a historicaltransaction between the customer and the first merchant or a secondmerchant; and based at least in part on the data associated with theunpaid invoice, causing presentation, by the merchant POS device and ona display of the merchant POS device, an invoice payment invitation forthe customer to make the payment on the unpaid invoice.
 39. The one ormore non-transitory computer-readable media of claim 38, the actsfurther comprising: receiving, at the merchant POS device and responsiveat least in part to causing presentation of the invoice paymentinvitation, input comprising invoice payment information associated withthe payment of the unpaid invoice; and responsive at least in part toreceiving the invoice payment information, transmitting, by the merchantPOS device, the invoice payment information to the one or more servers.40. The one or more non-transitory computer-readable media of claim 38,the acts further comprising: causing presentation, by the merchant POSdevice on the display of the merchant POS device, a request for apasscode from the customer for accessing invoice details associated withthe unpaid invoice; and responsive to receiving the passcode, causingpresentation, by the merchant POS device, of the invoice paymentinvitation, wherein the invoice payment invitation includes the invoicedetails.